Why does this part use string instead of integer? As far as I know, range partition uses a number. And we can check the range is valid (start < end) if we use integer.

What do you think of this configuration layout?
(Do we need a range block?).

range_partitioning:
  field:  customer_id # document uses `column` but this plugin uses `field`. [1] 
  start: 1
  end: 1000
  interval: 10
  # [1] https://cloud.google.com/bigquery/docs/creating-partitioned-tables#create_an_integer-range_partitioned_table

(This is just my opinion, I want to ask co-maintainers this comment.)

Thank you for the comment! I followed the api documentation. If you prefer integer, I'll change this!

https://cloud.google.com/bigquery/docs/reference/rest/v2/tables#RangePartitioning

Do we need a range block?

I fixed it with 49d2c36.

Hello, @kitagry. Thank you for waiting.

Could you use this layout? (Sorry, we decided to use the original design (except using integer instead of string in range values.)

range_partitioning:
  field: customer_id
  range:
    start: 1    # integer not string.
    end: 99999  # integer not string.
    interval: 1 # integer not string.

and Could you check the range start + interval < end?
If you have any concern, please let me know.

I referenced the time_partition configurations.

BigQuery API use

{
  "type": string,
  "expirationMs": string,
  "field": string,
  "requirePartitionFilter": boolean
}

embulk configuration

  type: bigquery
  table: table_name$20160929
  time_partitioning:
    type: DAY
    expiration_ms: 259200000 # integer not strong, use sake case

We discussed this using this design document. (Written in Japanese)

After modification, I'll check the partition feature.

Could you elaborate on this part? IIUC Helper.has_partition_decorator?(task['table']) returns true if the table name contains $. why you add task['range_partitioning'].nil??

I can't understand If user specify range_partitioning, it should be used as is means.

In my opinion, these checks are preferable.

# can't use two partitions config at the same time.
if task['time_partitioning'] && task['range_partitioning']
  raise ConfigError.new ...
end

# partition decrator doesn't support range_partition (if needed)
if Helper.has_partition_decorator?(task['table']) && task['range_partitioning']
  raise ConfigError.new ...
end

Thank you for the review. I think that the following code would be preferable.

if Helper.has_partition_decorator?(task['table'])
  task['time_partitioning'] = {'type' => 'DAY'}
end

if task['time_partitioning'] && task['range_partitioning']
  raise ConfigError.new ...
end

Hmm, the error message would be confusing. I fix like e9cc945. Could you check this?

(This is just a double check.) the error message means If user specify range_partitioning, it should be used as is?

When I use like following. Users who use partition decorator may be confused, because he don't use time_partitioning.

if Helper.has_partition_decorator?(task['table'])
  task['time_partitioning'] = {'type' => 'DAY'}
end

if task['time_partitioning'] && task['range_partitioning']
  raise ConfigError.new "`time_partitioning` and `range_partitioning` cannot be used at the same time"
end

Oh, you mean if the user uses the following configuration, the user may confuse the storage message. correct?
If so, your proposed PR seems good.

  table: part_test$200105
  range_partitioning:
    field: id
    range:
      start: 1
      end: 5001
      interval: 500